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Abstract. The Tor anonymity network depends on volunteers to oper- 
ate relays, and might offer higher bandwidth with lower response laten- 
cies if more users could be incentivized to contribute relay bandwidth. We 
introduce TEARS, a system rewarding useful service with traffic prior- 
ity. TEARS audits relays and rewards them with anonymous coins called 
Shallots, proportionally to bandwidth contributed. Shallots may be re- 
deemed anonymously for Priority Passes, which in turn may be presented 
to relays to request traffic priority. The PriorityPass construction enables 
relays to prevent double spending locally without leaking information. 
Unlike previous incentive proposals, TEARS incorporates transparent 
and distributed banking using protocols from distributed digital cryp- 
tocurrency systems like Bitcoin. Shallots are publicly- verifiable, minimiz- 
ing reliance on and trust in banking authorities, making them auditable 
while naturally distributing bank functionality and associated overhead. 
Further, these distributed banking protocols resist denial-of-service at- 
tacks and can recover from catastrophic failures. TEARS may either be 
deployed in the existing Tor network or operate alongside it. 


1 Introduction 

Tor is the most popular deployed anonymous communication system, cur- 
rently transferring over 8 GiB/s in aggregate [32]. The bandwidth Tor requires 
is donated by altruistic volunteers without any direct return on their invest- 
ment. As a result, Tor has primarily grown through the use of social and po- 
litical means. However, utilizing volunteer resources without providing incen- 
tives to contribute may not be an adequate long-term growth strategy. How 
to recruit bandwidth providers while maintaining anonymity is a well studied 
problem [1,7,15-17,25,26]. For several reasons, however, a number of practical 
changes to Tor would be required before adopting any incentive-based resource 
model; none of these have yet been implemented. 

In this paper, we draw upon the distributed Bitcoin architecture to design a 
transparent, efficient, and auditable reward system (TEARS) for Tor that 


rewards relays for providing useful service to the network. The TEARS archi- 
tecture uses existing anonymous Bitcoin protocols to create a type of “altcoin” 
token system that Tor may utilize internally to provide a means to obtain prior- 
ity service, and to provide an incentive to contribute bandwidth or other useful 
services. In TEARS, relays’ bandwidth contributions are audited and earn them 
Shallots, anonymous but auditable electronic cash. Relays may redeem their 
Shallots for relay-specific PriorityPasses, which they may “spend” as clients to 
request traffic priority [10]. Relays may also privately transfer their Shallots to 
any user wishing to obtain PriorityPasses. Accountability of Shallots is managed 
by a distributed and semi-trusted bank using a transparent, publicly auditable 
banking protocol [19]. 

Previous Tor incentive schemes that propose payments for service [1,7] trade 
off the speed at which double spending may be detected for the amount of 
information leaked through withdrawal and deposit transactions. In TEARS, 
relay-specific PriorityPasses allow relays to prevent double spending immediately 
and locally, without leaking information. Further, PriorityPasses in TEARS are 
non-transferable and become useless after they are presented, reducing over- 
head while ensuring that the process of requesting priority does not significantly 
degrade anonymity — the act of redeeming Shallots for PriorityPasses will be 
unlinkable to any later transaction. 

To the best of our knowledge, we are the first to describe how to distribute 
the bank among the Tor directory servers and utilize it in a way that protects 
the anonymity of Tor users. The bank in TEARS uses auditable distributed 
electronic cash protocols [22, 29] to realize transparent accountability of relay 
rewards while minimizing trust in authorities. Previous schemes assume the ex- 
istence of a central bank to manage the dissemination of relay rewards [15, 16]. 

In addition to outlining the design of a new Tor incentive system based on a 
distributed bank, we offer extended commentary on some system design decisions 
common to many Tor incentive systems in order to inform new research. This 
paper also discusses the social challenges involved in the deployment of TEARS 
and other radical design changes. We hope to illuminate the challenges and 
research problems in a way that will provoke useful discussion in the community 
while facilitating future research in this area. 

Section 2 first identifies basic requirements for an incentive design. Section 3 
outlines the TEARS architecture, then Section 4 discusses the potential impacts 
of design decisions on the existing network and its operators. In Section 5 we 
outline previous Tor incentive proposals and their shortcomings. Finally, we 
summarize open research problems and conclude in Section 6. 

2 Requirements 

A Tor incentive system that rewards volunteers for providing useful network 
services presents numerous requirements and challenges, both technical and so- 
cial. This section identifies the major technical problems we believe such a sys- 
tem should solve, keeping in mind that solutions should operate “out-of-band” 
to minimize interference with Tor’s low-latency communication design. See Sec- 


tion 4 for a discussion of social challenges involved in deploying a Tor incentive 
system, and Appendix A for a discussion of useful services. 

Preservation of Anonymity The system should not introduce new attacks 
on the anonymity offered by Tor. As such, the mechanisms used in our reward 
system should not allow users to be linked to their Tor network usage. 

Rewards for Providing Service Members that contribute to the system 
should be rewarded in proportion to the value of their contribution. Ideally, the 
reward should have a backing value, in that a member can use it to achieve a 
desirable system service or attribute. 

Proofs of Useful Service A system that rewards members for serving the 
network should be able to prove that those services were in fact rendered. Ideally, 
the proofs of service would be publicly verifiable so that any member of the 
distributed network could validate the utility provided by any other member. 

Publicly Auditable Accounting The system should provide a way to ac- 
count for the rewards obtained by each member, and provide facilities for the 
exchange of rewards. Double spending of rewards should be prevented or de- 
tected and handled. Ideally, the process of accounting for rewards should be 
publicly verifiable in order to minimize trust in centralized entities. 

Deployability The system should integrate well with the existing Tor network 
in order to maximize the utility provided to existing users and leverage the 
existing infrastructure and community. Ideally, the system components will be 
modular so they may be deployed incrementally. 

3 Architecture 

We now discuss how we realize a practical system for rewarding Tor relays. 

3.1 TEARS Overview 

TEARS embodies incentives in tokens called Shallots. To obtain Shallots, relays 
simply forward traffic as usual: their bandwidth contributions are audited and 
used to reward them with Shallots. Users may redeem Shallots for PriorityPasses, 
which they may present to Tor relays for temporary traffic priority. Relays will 
support a new circuit scheduler that will enable them to prioritize PriorityPass 
traffic over normal traffic. Once redeemed, PriorityPasses become useless. 

As in Bitcoin, TEARS users may create accounts simply by generating pub- 
lic/private keypairs. Shallots may be transferred between these accounts, en- 
abling third party markets to form; relays provide the initial supply of Shallots, 
and can trade them with regular users who demand prioritized Tor service. Addi- 
tional Shallots may also be minted and distributed to users for free, according to 
some prescribed (and publicly known) policy. (See Section 4.2 for more informa- 
tion about the monetary policy and how to “bootstrap” the system.) Allowing 
regular users and not just relays to obtain Shallots (and therefore PriorityPasses) 
helps obfuscate the source of prioritized traffic, a key goal also motivating other 
recent incentive designs [15,16]. Figure 1 illustrates the TEARS architecture. 
We next discuss the design of Shallots and PriorityPasses in more detail. 



Fig. 1 . An overview of our TEARS system, (a) A distributed process audits Tor relays’ 
bandwidth services and informs the bank, who then mints new Shallots for each relay 
and deposits it on their behalf, (b) Tor clients redeem Shallots for anonymous and 
unlinkable PriorityPasses at the bank through an anonymous Tor tunnel, (c) Tor clients 
present PriorityPasses for traffic priority at Tor relays, after which the PriorityPasses 
become useless, (d) Shallots can also be transferred from one user to another, as often 
as desired. Shallots may be given out for free via a “faucet”, and an external market 
may form around the exchange of Shallots for currency such as U.S. Dollars, Bitcoin, 
or other credentials deemed valuable by Tor users. 


3.2 Accountable Banking with Shallots 

Although the cash tokens in TEARS are initially minted and disbursed to users 
who contribute bandwidth, and are eventually redeemed as PriorityPasses in 
order to request enhanced service, the cash can be transferred among users any 
number of times in between. Users transfer tokens by communicating with a 
bank. We envision that the bank system will be operated by (a quorum of) 
semi-trusted servers, in particular the existing Tor directory servers. Although 
we refer to these servers as semi-trusted , , we nonetheless design the system to 
minimize reliance on them. The key design choices are enumerated below: 

Unconditional Privacy The tokens should be e-cash. In particular, even if all 
the bank servers are compromised, users’ transactions should still be unlinkable 
and private. This suggests that users should communicate with the bank system 
only through an anonymizing relay such as Tor itself. 

Auditability The bank servers should be unable to violate the basic proper- 
ties of a token currency — such as redeeming “counterfeit” tokens or transmitting 


“defective” tokens to honest users — without getting caught. This means we must 
use a publicly verifiable (or auditable ) e-cash protocol [22,29]. These schemes uti- 
lize non-interactive zero-knowledge proof systems. The bank maintains a public 
set of coins (public keys), and a user spends a coin (without revealing which) 
by proving possession of the private key for some coin not yet spent. In these 
schemes, it is safe to publish all messages between user and bank. In fact, any in- 
valid messages from a bank or user are immediately detectable by anyone reading 
the transcript, without private information, even if users and banks collude. 

We have mentioned that Shallots are initially minted in receipt of proofs of 
useful bandwidth contribution; other rules for minting Shallots may be supported 
as well, such as granting an additional fraction of each minted token to the 
administrators of the Tor Project. Such possibilities are discussed in more detail 
in Section 4. In all cases, however, an invariant to maintain is that the total 
quantity of currency in the system at any time is a matter of public record. 

Availability Any majority of correctly-functioning servers should be sufficient 
for banking service to continue uninterrupted, despite Byzantine failures of the 
others; additionally, no user that is able to connect to a correct server should be 
denied service. Due to the use of an auditable e-cash protocol as described above, 
the role of the bank is essentially reduced to receiving transactions from users 
and assigning to them a sequential ordering. Any efficient variation of Byzantine 
Paxos [19] can be used so that the correctly-functioning servers arrive at an 
agreement about the next batch of valid transactions to include; after reaching 
agreement, the majority of servers then produce a threshold signature [5,27] over 
these transactions and a sequence number. 

Transparency via Gossip or Broadcast As described above, an auditable e- 
caslr protocol is chosen so that every transaction can safely be published and any 
misbehavior detected. However, this is only valuable if members of the public 
are indeed watching and dutifully inspecting the published data. Users and other 
interested parties should gossip about any messages received from bank servers, 
similar to Certificate Transparency [20] . In order to detect a double-spend or oth- 
erwise invalid transactions, some member of the gossip network must maintain 
a copy of the set of outstanding (i.e., minted but not-yet-redeemed) Shallots. 

Alternatively, if a public broadcast channel is available, then interactions 
with the bank may simply be conducted over this broadcast channel. The Bitcoin 
blockchain is arguably a candidate for this, since arbitrary data may be included 
in Bitcoin transactions. This provides the further advantage that even a majority 
of the bank servers would be unable to selectively refuse service to clients; on 
the other hand, Bitcoin transactions generally require fees. 

Recovery from Catastrophe We have described above a publicly-auditable 
e-cash system that resists any misbehavior by a minority of the bank servers, 
and furthermore guarantees that misbehavior by even a majority of the servers 
is at least detectable. Suppose such misbehavior occurs — for example, that all of 
the bank servers collude to print their own counterfeit Shallots and then to sell 
them in external markets — and that the misbehavior is detected as intended. 


What should become of the system? Even in this catastrophic scenario, the 
system (including most Shallots) could be largely salvaged, as long as new (and, 
hopefully, more trustworthy) bank servers can be appointed. Since the history 
of Shallot transactions is public knowledge, the new bank can simply resume 
processing from a “fork” before the counterfeit event occurred. 

Redeeming Shallots for PriorityPasses In our e-cash description above, we 
said that users “spend” Shallots by proving they possess a private key and that it 
has not yet been spent. The transaction published by the user must also indicate 
how she wishes the Shallots to be spent; two options are available. First, if a 
user wishes to transfer the Shallots to another user, then the transaction should 
contain a commitment to the recipient’s public key. The second option is to re- 
deem Shallots for relay-specific PriorityPasses. This similarly involves providing 
a commitment to the relay’s public key. However, the two transaction types are 
distinguishable, and, unlike Shallots, PriorityPasses cannot be transferred again. 
Thus the total quantity of Shallots in the system consists of the total quantity 
minted minus the total quantity converted to PriorityPasses. 

3.3 Using PriorityPasses 

Once a user has obtained a PriorityPass, she can present it to the intended 
relay by opening the commitment in a single private message (which, as in 
BRAIDS [15], may be contained within an onion- wrapped message). Thus, with- 
out needing to interact with the bank, the relay can confirm the PriorityPass is 
dedicated to itself and has not previously been presented. 

To be suitable for use in Tor, PriorityPasses must be unlinkable and pri- 
vate so that clients’ payments to relays do not deanonymize their traffic. A 
major problem with most electronic cash in the context of Tor is that it must 
be deposited after being spent in order to realize payment and detect double 
spending: the timing of the withdraw and deposit operations leaks information 
about the source of Tor traffic, even if the cash itself is unlinkable (see Ap- 
pendix B for more details). Therefore, no hank communication should occur 
after relays receive PriorityPasses. To achieve this, PriorityPasses are locally 
verifiable, have non-transferable value (are useless after they are spent), 
and are bound to a relay identity: because PriorityPasses are relay-specific, 
each relay can immediately and locally prevent double spending. Finally, Prior- 
ityPasses are non-transferable: the relay identity bound to the PriorityPass 
may not be altered and PriorityPasses should not be transferred among users. 

While the cryptographic construction of PriorityPasses is out of scope for 
this paper, they may be produced using blind signatures so that the bank will 
not be able to determine the relay identity bound to each PriorityPass. 

3.4 Prioritizing Traffic and Auditing Bandwidth 

To provide service enhancements after receiving PriorityPasses, relays will sup- 
port a new circuit scheduler based on Proportionally Differentiated Services [9, 
10] that is capable of proportionally prioritizing traffic belonging to different pay- 
ment classes. This approach was also used in both BRAIDS [15] and LIRA [16], 


and details about how this type of scheduler would replace Tor’s existing circuit 
scheduler was outlined by Jansen [13]. We provide a summary in Appendix C. 

TEARS also relies on a secure method for auditing relays’ bandwidth con- 
tributions. While some work has been done in this area [11,30,31], we do not 
believe any existing design to be suitable for TEARS. While designing a band- 
width auditing system is out of scope for this paper, methods for accounting 
for bandwidth in general, as well as the limitations of existing measurement 
techniques, are discussed in Appendix D. 

4 Discussion and Open Problems 

Section 2 noted some of the technical requirements for a viable Tor incentive 
scheme, but there are deployment and social challenges as well. We outline these 
here, and defer a more extended discussion to Appendix E. 

4.1 Incentives to Participate 

Why should relays follow the protocol and actually give clients priority in ex- 
change for PriorityPasses? 

We’ve mentioned earlier that once PriorityPasses are spent, they are there- 
after nontransferable and out of circulation, and therefore useless. It is, however, 
possible for a relay to prove to the world (i.e. , in a publicly verifiable way) how 
many unique PriorityPasses it has received and processed. Relays may be inter- 
ested in publishing such information for the sake of informal bragging rights, even 
absent any formal recognition or reward; alternatively, relays that demonstrate 
receipt of PriorityPasses might be entitled to additional minted Shallots. In ei- 
ther case, it’s important that relays do not immediately publish PriorityPasses 
they receive, since this would enable timing analysis and threaten the anonymity 
of users. At most, relays should publish the PriorityPasses they receive period- 
ically (for example, once a month). If receipt of PriorityPasses entitle the relay 
to additional Shallot rewards, this process should also be scheduled periodically 
to avoid creating any perverse incentive for relays to compromise user privacy. 

4.2 Market Economics 

TEARS allows quantities of the currency to be transferred from one user to 
another; however, no explicit market-making mechanism is provided. We believe 
that as long as the Shallots are transferable, then third-party services will arise 
to satisfy any demand for trading Shallots for other currencies like U.S. dollars 
and Bitcoin. This has been the case with Bitcoin, for example, although the 
ecosystem of currency exchanges serving the Bitcoin community has involved a 
high degree of failure and fraud [24]. We leave the issue of establishing more 
trustworthy digital currency exchanges as an open problem. 

As previously mentioned, Shallots are initially minted and disbursed to relays 
as a reward for contributing bandwidth. While this is one way for new Shallots to 
enter the system, other supplementary minting policies are possible as well. For 
example, the administrators of the Tor Project may be designated to receive a 
fraction of each minted Shallot (i.e., as a form of tax), receive a small fraction of 
a Shallot whenever transferring Shallots among users (i.e., as a transaction fee), 


or even to print new currency at their discretion. An expiry might be assigned 
to each minted Shallot, such that it must be spent within some time interval or 
else is removed. These decisions constitute the monetary policy of TEARS, and 
we leave choosing appropriate parameters as part of deployment strategy. 4 

Allowing the administrators of the non-profit steering organization to receive 
additional currency has several benefits; in particular, the Tor project might 
operate a “faucet” 5 that gives small amounts of Shallots to individual users 
who might not have money or access to currency exchanges. Due to the bank 
system’s public auditability, even if administrators can mint new currency at 
their discretion, the total amount minted would be publicly visible. 

The ability for users (other than relays) to obtain Shallots via the faucet 
mechanism as well as third-party markets is important as it provides a non-trivial 
amount of added security: without these mechanisms, only service providers 
would be able to accumulate Shallots and would therefore be more easily identi- 
fied as a potential source of traffic on circuits where PriorityPasses are presented 
for priority. However, we note that we want the system to be accessible to as 
many users as possible, and so Shallots and PriorityPasses should always be an 
optional part of the system and should never be required to receive basic service. 

4.3 Community Effects 

Adding explicit incentive mechanisms to a system like Tor that relies on vol- 
untary behavior can have perverse effects. This has been widely observed, and 
quoted here from Benkler [2]: 

Compare the level of use and success of pay-per-cycle distributed 
computing sites like Gomez Performance Networks or Capacity Cali- 
bration Networks, as compared to the socially engaged platforms like 
SETI@Home or Folding@Home. It is just too simplistic to think that if 
you add money, the really good participants will come and do the work 
as well as, or better than, the parallel social processes. . . . Adding money 
alters the overall relationship. It makes some people ‘professionals,’ and 
renders other participants, ‘suckers.’ It is not impossible to mix paid and 
unpaid participants, as we see in free and open source software and even 
to a very limited extent in Wikipedia. It is just hard, and requires a 
cultural form that is definitely not ‘now at long last we can tell who’s 
worth something and pay them, while everyone else is just worthless.’ 

If a new incentive scheme is incorporated into Tor, there is a danger of such 
a crowding out of intrinsically motivated volunteers, thus reducing rather than 

4 Although Bitcoin, the first and currently most popular cryptocurrency, mints new 
coins only as a reward for network participation (and at a fixed rate, which is sched- 
uled to gradually diminish over hundreds of years), other competing “altcoins” such 
as Freicoin (http://freico.in/) implement alternate monetary policies such as 
demurrage and allocating a portion of newly minted coins to a designated adminis- 
trator. 

5 See https://en.bitcoin.it/wiki/Bitcoin_faucet for a list of faucets that offer 
small quantities of Bitcoin for free to users. 


increasing network size, diversity, and capacity. When faced with challenges to 
users, the network, or their relays, intrinsically motivated operators are more 
likely to resist on principle than someone for whom this is a mere economi- 
cally rational question. However, we have not proposed straightforwardly liquid 
compensation: contribution to Tor simply allows an operator to have prioritized 
traffic in relay queues, an enhanced version of the basic service you would already 
get for free (much like the members entrance at a zoo or museum). 

4.4 Recommended Deployment 

A deployment strategy for radical Tor design changes is challenging, especially 
for the TEARS system because of the many problems and risks outline above. 
Both for our own research questions and for other potential innovations, we 
believe it would be useful for Tor to offer experimental releases. Appendix E.2 
presents our rationale for this recommendation. 

Experimental releases would typically introduce features that already have 
been vetted through academic publication, have done the necessary network 
experimentation to satisfy the community, and might typically have associated 
Tor proposals. They should also have been through some degree of scrutiny from 
the Tor developers. Nonetheless, these should clearly be labeled as experimental, 
similar to the labeling of alpha releases. Participating relays should be capable 
of handling both experimental traffic and production Tor network traffic, and 
we assume that Tor should always support both clients and relays that choose 
to ignore any feature in any experimental release. 

To deploy TEARS using an experimental release and network, we expect that 
alternative consensus files would be created while new infrastructure may be re- 
quired to provide an operational incentive network (e.g., new directory servers 
that also run the TEARS bank). Users that would like to try out TEARS features 
could use the new experimental consensus to choose relays supporting TEARS 
as part of the experimental release; other users would ignore the experimental 
release and continue using Tor as usual. We believe this deployment path will 
help reduce risk to the existing production network while still providing useful 
information about the potential deployment of new designs. We can also deploy 
all the experimental mechanisms and software for purposes of testing and bug 
fixing but initially turn the faucet mentioned in Section 4.2 on high. The infla- 
tionary effect will be to eliminate any value from prioritization since so much 
traffic will be eligible for PriorityPasses that prioritization will not provide sig- 
nificant performance benefit. Once TEARS has been deployed and tested it will 
then be possible to turn down the faucet at whatever rate and to whatever level 
is desired to evaluate the effect on prioritization and prioritization-motivated 
contribution to the network. In this way we can separate the deployment and 
testing of the experimental software from the experimentation with incentives. 

5 Related Work 

Tor-specific incentives systems have been studied many times before, but 
none of them discuss how to use a decentralized transaction processing service 
to handle the management of accounts. 


Ngan et al. propose that the fastest 7/8 of relays get flagged as gold star 
relays in the consensus, and that gold star relays prioritize the traffic that is 
initiated at other gold star relays [26]. Similarly, Tortoise applies a universal 
rate limit to all clients, but exempts those that run relays marked with the fast 
and stable consensus flags [25]. Both of these approaches severely harm the 
anonymity of relays using Tor’s client functionality: the set of potential initiators 
for traffic receiving priority (or not being throttled) can be narrowed from the 
full set of clients to the set of relays with the correct flags. 

Monetary payments are offered in exchange for routing services in PAR [1] 
and XPAY [7], where digital coins are inserted into the routing protocol. Clients 
obtain coins from a centralized bank, and relays must send coins back to the 
bank soon after receiving them in order to detect double spending. The timing 
of the withdrawal by the client and the deposit by the relay may leak information 
about the client’s traffic. Coins may be held by the relay longer to disrupt this 
timing information, but it also reduces the speed at which double spending can 
be detected. 

The double spending problem was eliminated in BRAIDS [15] with the intro- 
duction of relay-specific tickets: relays themselves are responsible for verifying 
that their tickets have not been previously spent without contacting the cen- 
tralized bank. BRAIDS does not require clients to provide a ticket in order to 
use the system, and freely distributes a small amount of tickets to all users. 
Although this increases the difficulty in distinguishing clients from relays based 
on their payments, relays also accumulate tickets for providing service and will 
therefore still be able to receive traffic priority more often than clients. Finally, 
BRAIDS is somewhat inefficient in that it depends on a central bank that must 
continuously exchange tickets for all users. 

The efficiency of a central bank was improved in LIRA [16], where a crypto- 
graphic lottery was used to decide when clients could receive priority. In LIRA, 
clients simply guess a random number and receive priority with tunable prob- 
ability. The central bank only has to manage accounts for relays, who receive 
the ability to obtain guaranteed winners to the lottery in exchange for providing 
service. Unfortunately, probabilistic guessing reduces flexibility for clients want- 
ing to receive continuous priority over time, and creates a potential for cheating 
the system because it enables clients to continuously create circuits until a cor- 
rect guess is found. Finally, LIRA relies on both a central bank and a secure 
bandwidth measurement system to inform the bank about the number of guar- 
anteed winners each relay is allowed to obtain; as we will discuss, measuring 
relay bandwidth securely is an open research problem. 

Johnson et al. argue that Tor should allow its services to be purchased [17] 
to take advantage of a large pool of new users that already pay for tools that 
circumvent censorship without the strong privacy guarantees that Tor offers. 
This new pool of clients could help fund new service providers and could increase 
Tor’s anonymity by diversifying its traffic sources. 


6 Conclusions and Future Work 

In this paper, we presented the design of the first Tor incentive system that 
is based on a distributed bank with fully transparent and auditable protocols for 
accountability. We believe our system minimizes the trust placed in the banking 
authorities while reducing or eliminating problems related to the double spending 
of tokens, the information leaked by transactions, and the processing limitations 
of a central bank. 

Future Work There are several open problems that future work should con- 
sider. TEARS relies on a bandwidth auditing service to securely measurement 
relays’ contributions. We believe that more work is needed to determine the ex- 
tent to which previous bandwidth measurement proposals [30,31] may help fulfill 
our requirement. Another challenging problem is how to prove that a relay was 
honest in giving priority when presented with a PriorityPass, and how to prove 
the relay did not change the scheduling parameters set by the network. 

More work is needed before TEARS can be deployed. A system analysis 
should be done to ensure TEARS provides the properties we claimed it does, 
and an efficiency analysis should be done to determine the scalability as both 
the number of relays and the number of banking authorities increases. In addi- 
tion, experiments with TEARS should be done using tools like Shadow [14] to 
determine how performance changes as the number of PriorityPasses that are 
available to users varies. Finally, usability and behavioral analyses would be ex- 
tremely useful in helping to understand how an incentive system would affect 
the altruism of the existing community of volunteers. 
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Appendices 

A Useful Service in Tor 

The main goal of a Tor incentive system is to convince users that they should 
contribute useful services to the network by providing rewards. A Tor service may 
include bridge, guard, middle, and exit relays, directory authorities and mirrors, 
and hidden service directories. While simply running these services may provide 
some benefit to the network, composing any of the following properties will 
generally increase utility: 

— High bandwidth: more bandwidth to better support Tor’s load. 

— Location diversity: expanding Tor’s reach to geographic regions containing 
few or no relays will help users route around untrusted parts of the Internet. 

— Stable: longer uptimes improves network stability. 

— Exit policies: liberal exit policies will increase relay utility. 

— Metrics: share relay or other statistics about network operation. 

— Newer Tor versions or support for experimental features. 

There is no direct existing means to encourage useful service such as location- 
diverse or high bandwidth relays. As a result, existing Tor relays naturally grav- 
itate towards familiar, cheap, and Tor friendly ISPs, and many of them provide 
such a low level of bandwidth that their relays are rarely chosen for client cir- 
cuits. An incentive design could differentially reward contributions based on their 
usefulness to the network. While this may add complexity to the process for ver- 
ifying contributions, it would allow Tor to get the most out of its contributors. 

An incentive design could incorporate a diversity weight to provide rewards 
for relays based on location thus improving general security as well as perfor- 
mance of the Tor network. We could also create a super-linear reward scale to 


encourage higher bandwidth capacity relays, or a sub-linear scale to encourage 
greater uniformity of relay bandwidth. Although it is clear that useful service 
is certainly not limited to relay bandwidth, we focus on it in this paper as it is 
currently the most demanded Tor resource. 

B Payments Leak Information 

To request a service or service enhancement, clients in a Tor incentive system 
generally need to provide some kind of bank-authorized payment to the relays. 
These payments sometimes use electronic cash schemes, but are usually con- 
structed with blind signatures and zero-knowledge protocols. For the purposes 
of this section, we will refer to these digital certificates more generally as certs. 

Certs provide unlinkability between when they are withdrawn from the bank 
and spent at a merchant, making their use in a system of accounting an at- 
tractive option for an anonymity network like Tor. Here we discuss how using 
certs to request enhanced service may leak information in Tor. Further, if re- 
lays’ contributions are accounted for via an independent process (as discussed 
in Appendix D), then the question of “ Should the certs themselves have value to 
the relay?" can be thought about by considering the roughly analogous notion 
of receiving “tips” in addition to “salary” . We will also briefly speculate on how 
this may affect relay behavior. 

B.l Certs that Retain Value After Transfer 

With generic certs that have transferable value, the merchant must generally 
deposit each cert immediately in order to detect double spending. Because the 
timing of the withdraw and associated deposit can leak information about a 
client’s usage activity to the bank, the client should add some “mixing time” 
before spending it to improve unlinkability at the cost of flexibility. 

Relay-specific certs help mitigate this problem to some extent, because the 
relays are able to prevent double spending locally. However, if these certs retain 
value that can be transferred to another relay, then the receiving relay will still 
need to deposit certs it receives via transfers. The receiving relay should add 
some amount of “mixing time” before depositing transferred certs, to obfuscate 
from the bank the withdraw operation associated with each deposited cert. Some 
flexibility in usage is lost because the certs are good only at a single relay unless 
they are transferred, and they must be mixed again before each transfer. 

To summarize, with general certs: 

— clients may use them at any relay; 

— relays should deposit them immediately to detect double spending; 

— clients should delay usage after withdrawal to reduce linkability; 

With relay-specific certs: 

— clients withdraw them from the bank for specific relays (the chosen relay is 
blinded to the bank); 

— clients may spend them immediately; 

— relays may prevent double spending locally; 

— relays should delay deposit after receipt to reduce linkability; 


— long delays are imposed if clients exchange unspent certs (e.g., because the 

relay bound to the original cert went offline). 

The “mixing” happens on the client end with generic certs, and the relay 
end with relay-specific certs. These approaches may be complimentary, such 
that combining them would improve flexibility: clients keep a stash of general 
certs usable anywhere in the long term, and supplement that with relay-specific 
certs usable at a single relay in the short term. 

If we allow clients to “tip” relays - by directly transferring value to relays 
above and beyond the system’s normal reward mechanism based on measured 
bandwidth - then we create an incentive for relays to provide service differenti- 
ation (see Appendix C). If this incentive exists, a selfish relay will always prefer 
to forward “paid” traffic over “unpaid” traffic. Relays will try to make priority 
traffic as attractive to clients as possible, and thus prefer scheduling parameters 
that result in bigger performance boosts. With enough “tipping” clients, the 
“non-tipping” clients would eventually stop using relays that provide horrible 
service to them. Of course this will always be true to some extent due to the 
functionality of the scheduler, but relays would have a reason to adjust their 
scheduler in a way that forces the situation earlier. 

B.2 Certs that are Valueless After Transfer 

With relay-specific certs that have no transferable value, the relay can simply 
detect double spending locally without ever depositing anything back to the 
bank, thereby addressing the linkability problem. However, some flexibility is 
lost in this design because the certs are bound to specific relays and cannot be 
transferred to other relays. Further, relays would need to earn rewards via a 
separate channel (such as a collective bandwidth measurement mechanism as 
proposed in this paper). 

If we do not allow “tips” or re-use of certs by the relays, then we expect 
the relays to remain agnostic about the operation of the scheduler. They will 
be happy as long as they are able to provide bandwidth, because that is how 
they receive rewards. This will allow Tor to better control the scheduling pa- 
rameters in a way that makes service for “non-tipping” clients bearable. The 
relays have an incentive to follow the protocol, because otherwise clients may 
be able to detect malicious behavior, and might even form a reputation system 
to gossip opinions about relays exhibiting bad or suspiciously deviant behavior. 
While proving that relays didn’t change their scheduling parameters would be 
challenging, at least they don’t have a direct incentive to be dishonest - provided 
the collective bandwidth measurement mechanism is secure and relays cannot 
game it to collect rewards disproportionate to the utility they offer. 

Given the discussion in this section, we believe the benefits of relay-specific 
certs without transferable value outweigh the loss in flexibility, and therefore 
designed PriorityPasses accordingly. 

C Rewards for Providing Service 

Relays will receive rewards for their useful contribution to the network. We 
believe a desirable reward for providing service is preferential treatment of traffic 


by bandwidth providers. We intend that rewards be used to enhance performance 
by differentiating the traffic priority of rewarded flows from unrewarded flows. 
Note, however, that this approach does not guarantee service differentiation, 
because the ability to provide performance enhancements depends on network 
dynamics such as relay capacities and client load distribution. 

C.l Differentiated Services 


The differentiated services architecture [4] can be used to improve the control 
over traffic priority in Tor, as previously outlined by Jansen [13]. More specifi- 
cally, the proportional differentiation model [9] allows for predictable (i.e. , con- 
sistent as load increases) and controllable (i.e., adjustable differentiation) per- 
formance between N traffic classes. The model allows for the configuration of a 
differentiation parameter pi for each class i, and enforces the proportional prior- 
ity of a traffic quality metric q between all pairs of classes i and j for measurement 
timescale a as: 
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where p\ < ... < pn and Pi/pj defines the quality proportion between classes i 
and j . The model is well defined when there is enough traffic in each class to 
allow a work-conserving scheduler to meet the desired proportions. 

Dovrolis et al. design a scheduler under the proportional differentiation model 
using a queuing delay metric [10], which in our case corresponds to Tor cell 
waiting times. For class i, the quality metric qi combines the queuing delay 
Di{t) of the longest waiting cell with the long-term average delay 8i(t) of all 
previously scheduled cells at time t : 


qi{t) = Di(t) ■ f + Si(t) ■ (1 - /) (2) 

where / is an adjustable fraction that tunes the scheduler’s ability to react to 
short term spikes in delay. When a scheduling decision is to be made at time t , the 
longest waiting cell from the class with the maximum priority P(t) = q(t) /p(t) 
is chosen and scheduled. 

C.2 DiffServ Parameters 

Any number of classes can be configured as well as the prices and proportions 
between them. We suggest three service classes: basic (free), standard, and pre- 
mium. Clients can select their priority class by supplying the correct number of 
PriorityPasses independently to each relay in their circuit, and each PriorityPass 
can provide the selected priority for a configurable amount of data. Although 
heuristic measurements could suffice, how to prove that a presented PriorityPass 
actually resulted in a service enhancement reward is an open research problem. 

C.3 Distinguishing Traffic by Priority 

We acknowledge that traffic priority will fundamentally allow users that are 
categorized into different service classes to be somewhat distinguishable from one 
another, which may result in a partitioning of Tor’s anonymity set. However, as 
Johnson et al. argue [17], users with lower security requirements may be willing 


to trade off reduced security for improved flexibility and performance: users 
already use Tor for downloading large files even though their activities look very 
different than most [6,21]. Further, a faster network that is more flexible (clients 
may specify their desired performance level) may attract a significant number of 
new users and result in a net increase in anonymity. We note that it is important 
to make clear to users the risks and trade-offs they assume by participating in 
such a network. 

D Bandwidth Accounting 

A Tor incentive system should provide a means to prove that the service was 
actually rendered, i.e. , to account for relay bandwidth contributions in a way 
that is accurate for all relay positions and in both upstream and downstream 
directions, is secure against cheating , and cannot link clients to the relays they 
choose, the circuits they use, or the traffic they send. 

In this section, we will use the generic term bwtoken to represent band- 
width contribution levels: obtaining bwtokens should be roughly correlated with 
contributing bandwidth. There are at least two methods for using bwtokens to 
account for bandwidth: 

1. relays receive bwtokens directly from clients in exchange for utilizing their 
bandwidth resources to forward traffic; and 

2. relays receive bwtokens indirectly through a distributed process that decides 
the number of bwtokens each relay should receive, e.g., based on bandwidth 
measurement audits. 

D.l Direct Accounting 

In order to use the first method above to accurately account for all contributed 
bandwidth, clients must be able to continuously send bwtokens in exchange for 
service in a way that does not break client anonymity and cannot be exploited by 
service providers to earn more bwtokens than they deserve. Also, relays should 
be able to use bwtokens to prove their contributions to other system members. 

The BRAIDS incentive scheme [15] shows how to use coin ripping [12] and fair 
exchange [28] to ensure that relays don’t receive “tickets” unless they actually 
perform the forwarding service. However, BRAIDS suffers from somewhat high 
performance costs because it distributes tickets to every client in the system 
(though tickets are not required to receive service). If all clients were required to 
use tickets so that we could accurately account for relay bandwidth, the overhead 
would also increase. 

In the TorPath scheme [11], participating clients work with the three relays 
on a Tor circuit to mint coins in proportion to the useful end-to-end band- 
width they observe. To prevent clients from choosing colluding relays to mint 
coins dishonestly, TorPath uses verifiable shuffles to assign relays to clients using 
secret but publicly verifiable randomness. This approach measures bandwidth 
end-to-end and limits the system’s vulnerability to unfair or malicious ticket 
distribution, at the cost of limiting clients’ freedom in choosing relays. 


We would like clients to receive enhanced service whether or not they are re- 
quired to directly handle bwtokens for bandwidth accounting purposes. Note that 
the problem of handling enhanced service payments without leaking information 
is discussed in Appendix B and is independent of the problem of accurately ac- 
counting for bandwidth contributions: although many Tor incentive schemes use 
a single token to handle both problems at once, this need not be the case. 

D. 2 Indirect Accounting 

Accounting for bandwidth indirectly requires a measurement infrastructure and 
service audit system that prevents providers from cheating to receive bwtokens 
disproportionate to their actual contributions. The LIRA incentive scheme [16] 
also relies on such a system. A bandwidth audit system measures the expected 
bandwidth at each relay and produces weights for the Tor consensus that are used 
during path selection. If accurate and secure, these weights could also dictate 
how to distribute bwtokens to relays in proportion to their contributions. Tor 
currently runs a bandwidth audit service, but it has been shown to be easily 
manipulable [3]. 

The most recent alternative Tor bandwidth measurement system is called 
EigenSpeed [30,31]. In EigenSpeed, relays opportunistically measure their in- 
teractions with other relays and send the observation vectors to the authorities. 
The authorities combine the measurements from all relays using principal com- 
ponent analysis (PC A), and produce a set of authoritative weights that can be 
distributed via the Tor consensus file. Unfortunately, EigenSpeed has the follow- 
ing problems: 

— It does not account for asymmetric bandwidth. 

— It is unclear how to measure relays acting in entry and exit positions. Since 
EigenSpeed measures only the peer-to-peer bandwidth relays offer each other , 
a relay might obtain a high EigenSpeed rating without ever accepting con- 
nections from non-relay clients or forwarding traffic to external destinations. 

— Because measurements are opportunistic, EigenSpeed tends to under-estimate 
the contributions of the fastest relays. 

— It is unclear how to handle sybil attacks by malicious collectives. 

Correctly attributing bandwidth contributions to providers via either of the 
two methods outlined in this section remains an open research problem, and one 
that future work should consider. 

E Extended Discussion 

E. l Direct Payment for Anonymity 

There have been previous approaches deployed involving some form of direct 
payment for Tor. It is instructive to consider what these do and do not provide. 
Torservers.net is an international federated consortium of nonprofit organiza- 
tions that uses donated funds to purchase service especially for large capacity 
exit relays in various locations (so far in the U.S. and Europe). This system 
offers direct financial payment for provided service rather than providing either 


basic service or service improvement as compensation. It also does not aspire 
to the market driven exchangeability of incentives that we envision. It is based 
more on the cost of running a given capacity server in a given market than on 
direct measurement of amount of service provided. 

A commercial pre-Tor onion routing network, the Freedom Network from 
Zero Knowledge Systems, was operated in the early 2000s. This network allowed 
clients to purchase a number of pseudonyms that were granted access to the 
Freedom Network, and like torservers.net, network relay operators were paid 
monetarily for bandwidth provided. This, however, was designed so that all 
network providers were expected to operate for compensation and essentially all 
clients were expected to pay proportionally to service obtained or contracted. 

E.2 Path to Deployment 

It may be useful for cleaner experimental results to deploy a separate pay net- 
work along the lines of Freedom, for example, to see the relation of differentiated 
service parameters to incentives for providing various amounts of service. Our 
long-term goal, however, is to grow the Tor network for all users regardless of 
ability to pay. Such experimental results are thus unlikely to be at all representa- 
tive of intended usage patterns and may thus be of limited usefulness- without 
even considering the impact of such partitioning on anonymity. 

This necessitates a plan for deploying an incentive scheme that dovetails with 
existing and otherwise planned Tor protocols and Tor infrastructure, which will 
thus require the explicit approval of principal Tor developers and the tacit ap- 
proval of a statistically large fraction of Tor relay operators, directory operators, 
etc. To gain the approval of developers, it is not enough to have vetted research 
results. Tor proposals [33] will need to be created and accepted. 

We will further explore the need for tacit relay operator approval presently. 
We note here simply that anything deployed should minimize major unpleasant 
surprises for relay operators. A measure of this might be resistance to adopting 
new Tor releases that incorporate new incentive mechanisms. Rollout must also 
be gradual in multiple senses: the more relays running versions of Tor incorpo- 
rating features of any incentive scheme are able to function smoothly with relays 
running versions of Tor without those features, the easier it will be to introduce 
those features into the network. At the same time, the more multiple incentive- 
scheme feature changes are simultaneously deployed rather than one at a time, 
the harder it will be to understand, isolate, and debug problems that inevitably 
arise when features are deployed in the wild. We can also separate rollout of a 
bank and network information directory system and associated experiments of 
their interaction with participating relays and simulated clients from subsequent 
rollout of experimental clients. 

Tor follows common practice of making alpha releases available to those who 
are willing to take some risks to help understand and debug new features be- 
fore they are incorporated into stable releases for the general user and operator 
population, for example, when introducing a new handshake or directory infor- 
mation protocol. This amounts to a live experimental network interoperating 
with the stable network. Alpha releases are, however, intended to incorporate 


features and changes that may need some further adjusting and debugging but 
are already intended for deployment rather than for experimental evaluation. 

Approaches to experimental research include simulation and live or testbed 
network experimentation. Shadow [14] permits full scale simulation of the entire 
current Tor network on a single server. But this cannot address a primary ques- 
tion of how incentives will affect behavior of client and relay operating users. 
PlanetLab has been used both for entirely experimental Tor networks and to 
run experimental relays that participate in the public Tor network. As a gen- 
eral shared network experimentation resource PlanetLab may not be suitable for 
sustained large scale experimentation involving differentiated service. Also, it is 
important to manage the sorts of experiments running on the live Tor network 
lest they significantly harm security or performance for the users or network ele- 
ments. We must also consider how to make client software adequately available. 

As discussed in Section 4.4, we advocate for a new experimental Tor release 
as a means for creating an experimental network. Research experiments may re- 
quire relays that are only capable of handling experimental traffic but that can 
pass this transparently to other parts of the Tor network. As with network ex- 
perimentation, some of the infrastructure may run on PlanetLab as appropriate, 
but that need not be the case. After experimental release, we expect appropri- 
ate parts of new designs to follow Tor’s traditional deployment process: first 
in alpha releases, then standard releases; older versions may eventually become 
unsupported. 

E.3 Managing Network Information 

Tor’s current directory system is distributed but centralized. A relatively small 
set of directory authorities (currently roughly 2.5 orders of magnitude smaller 
than the network) vote on the status of relays in the network. The results are 
pushed out to all relays so that, except when unusual problems arise, Tor clients 
do not need to interact with this small set. 

It is an open question how far Tor’s current approach will scale. However, it 
is unclear how far it practically needs to do so given the limitations to diversity 
of locations for a large adversary to observe in the underlying network [18]. The 
anonymity benefit of attempting to maintain a single uniform network picture 
versus allowing partitioning may not be as great as often assumed [8]. Nonethe- 
less, alternative approaches to distributing network information have been ex- 
plored in the research literature, including P2P and DHT based schemes and 
PIR schemes. None have yet been vetted to the point of deployment or even 
to having a Tor proposal. It is an open research question if decentralized coin 
systems already in use, such as Bitcoin, could be used for storage of Tor network 
information [23]. 


